[Elecraft] New DSP Idea

[David Gilbert]

Yes, I agree that the computation needs to be done in the frequency 
domain with an FFT.  I have no clue whether or not the K3 and K3s have 
enough computational power to do so, but Lyle (Elecraft's DSP guru) 
briefly discussed this idea with me when I suggested it several years 
ago and he seemed to think it might be feasible.  At the time the K3 
synths wouldn't preserve lock when you changed frequency so it wouldn't 
have been very practical back then, but the new synths are fed by the 
same oscillator now.

Regarding the direction finding part of my proposal, I once fed a 40m 
broadcast band carrier into both receivers of my K3 in diversity mode.  
I used my 2 element 40m yagi for one receiver, and the tribander below 
it for the second receiver.  I then fed the line output of the K3 into 
the sound card of my computer running an dual trace oscilloscope 
application.  I didn't know the actual delay of either feedline so I 
just set the app to trigger on one of the signals and then observed how 
my trace delay there was on the other signal.  I knew the audio 
frequency of the signals, the frequency of the RF, and the distance 
between the two antennas.  While I wasn't able to calculate the actual 
arrival angle without knowing the actual phase delay of each feedline, I 
was able to calculate/observe roughly how much it changed over time.  I 
had to wait for pauses between the voice modulation of the AM signal, of 
course, but after watching for several minutes I could see that the 
short term jitter was roughly 5 to 10 degrees and the longer term 
changes maybe about 15 to 20 degrees.  The results were enough to 
convince me that a better setup could give interesting information, and 
I suspect that the azimuth angle would be more stable than the arrival 
angle.

73,
Dave   AB7E


On 1/13/2019 8:45 AM, David Woolley wrote:
> Assuming that there is enough processing power available, and the 
> architecture physically allows the mixing, manually steering either 
> the peak or the null should be achievable.  There is a slight subtlety 
> in that one is trying to achieve a constant time delay at RF, not a 
> constant phase change, but, if RF is sufficiently higher than the the 
> baseband, it will be a good approximation, and the hardware devices 
> being quoted probably have the same defect.
>
> Automatically getting a direction is only accurately achievable if the 
> interfering noise is isotropic, at least in the plane containing the 
> line between the antennas. As such, it will not be able to 
> automatically get a direction for an interfering signal, unless it can 
> separate that signal from everything else, and if it can do that, 
> there may be more direct ways of removing the signal.
>
> The only way I can see of performing the computation is in the 
> frequency domain.  Although everything starts as just a time delay, 
> the down conversion preserves phase not time, so I think one needs to 
> do a Fourier transform, rotate each value by a fixed amount (or one 
> accounting for the offset from the carrier not being negligible) and 
> then invert the transform.  (There may be better algorithms.)
>
> Because of the discrete nature of FFTs, you would probably want to run 
> several overlapping transforms and average their results.
>
> I suspect the current DSP tries to avoid doing a full Fourier 
> transform, and even panoramic adapter FFTs don't need to run 
> overlapping transforms.
>
> I think the big question is does the machine have enough processing 
> power to do this.