If you can manage it physically, one trick to lower receive noise is to
vertically stack two shorter Yagis rather than using one long one. The
spacing will direct a null toward ground. At half-wave spacing, the null
will be directly below. This spacing is too small for best forward gain.
For wider spacing, the null moves out. For example, at 0.7 wavelengths
it is at 45 degrees. At one wavelength, it is at 30 degrees. The angles
might put the null right at your noisy neighbor's place. A null directly
below also reappears at one wavelength.
Note that the azimuth pattern of a horizontal Yagi is the free-space
elevation pattern multiplied by the E-plane response of a dipole. So any
adjustment to the elevation pattern to lower noise will affect the
azimuth pattern. Optimization to reduce the response in a region
centered directly below does the same thing to the azimuth pattern off
the ends. This is where it is already small due to the E-plane dipole
response. The additional drop is not likely to be of much benefit, and
it may hurt the response toward the rear.
An automatic optimizer can trade off everything if you tell it your
design preferences and constraints. It can even redirect its effort once
a performance objective has been met. I find all this impossible to
manage by manual optimization - it's been decades since I tried. The
neat thing about a good optimizer, particularly one that uses a global
algorithm rather than a local one, is that the final design is the best
possible according to your trade-offs. If you tweak the design to
improve one aspect, another will surely degrade. I always felt this was
rather magical. The trick is telling it what you want. Often you don't
know until you get some idea of the performance space and how one
objective naturally trades for another. I once designed an optimizer
that let you explore performance space using optimal designs. There was
a triangle that represented gain, pattern, and SWR trade-offs. You could
move a dot around inside the triangle with the mouse to dynamically
change the trade-offs. While you did this, the optimizer was running.
The idea is that all the designs you're exploring are the best possible
given the priorities you've set and they are shown on the screen as you
make trade-off changes. Computers weren't fast enough in those days to
instantly optimize a design, but they are today. The last time I
checked, which was eight years ago on single 3 GHz processor, my code
was calculating 165,000 8-element designs per second. Things converge
quickly to optimal at that rate! Try doing that with NEC. I've been
toying with the idea of resurrecting YO and adding modern methods, such
as multiple CPUs running in parallel. The problem of Yagi optimization
is readily separable and can be handed off to multiple independent agents.
That was quite a ramble. And I was just getting started. I better cut
this short and get some sleep. For some time now I've been getting up at
midnight and programming for 18 hours straight. I think it's finally
getting to me. This is what I've been working on:
https://k6sti.neocities.org/sp
Brian
_______________________________________________
_______________________________________________
TowerTalk mailing list
TowerTalk@contesting.com
http://lists.contesting.com/mailman/listinfo/towertalk
|