It's easy to see who's read Chapter 8 of the ARRL Antenna Book and who
hasn't! Denny has the right idea.

What you need to do in order to get a decent front/back ratio from the
two elements is to create equal amplitude and correctly phased fields
from them. If one is shorter than the other, it needs to get more
current to produce the same field as the longer one. The current at the
feedpoint of a shunt fed tower isn't equal in either magnitude or phase
to the current in the tower itself. So adjusting the feedpoint currents
for some relative magnitude and phase won't get you the right tower
currents unless you've accounted for the transformation.

It's much easier to get 2 - 3 dB gain than to get good f/b ratio -- you
can goof up the current magnitude and phasing pretty badly and still get
noticeable gain in about the right direction. (In a way it's too bad
this is true, because a lot of people see some gain and assume it means
that they've got the phasing they planned, when in reality they're way
off. Then they extend this misinformation to other arrays and can't
figure out why they don't work.) But with the setup you've described, it
would be easy to be far enough off that you wouldn't get the gain,
either, at least not in the expected direction.

It can be done, but as Denny says, it's much more complicated than just
using a 90 degree "phasing line" as another poster suggested. That
approach generally doesn't work for even the simplest of cases (see the
Antenna Book for the reasons), and it certainly won't work here. What I
would do is model the elements without the shunt feed system and adjust
the base currents in the model (by putting current sources at the bases)
to get the desired pattern. Then I'd make an adjustable feed system like
the L network feed described in the Antenna Book or one of the other
systems described in _Low-Band DXing_. Then I'd arrange some sort of
current probes at the tower bases and adjust the currents to match the
model currents. A final adjustment could be made by putting a signal
source or detector to the rear of the array and adjusting for the best
null. If you do everything just right, you'll get right at 3 dB gain
over a single element and a very good null directly to the rear.

A parasitic array is an option, but again I'd model it. You have the
same problem of getting the right element currents, but now the only
adjustment you can make is the parasitic tower's resonant frequency. You
might have trouble getting enough current in the short tower to do you
much good. A second problem with the parasitic array approach is that
any ground loss will eat you alive. Even what you consider to be a good
ground system might not be adequate, especially for the short element.
Be sure to include a realistic amount of ground system loss in any model
you make.

Alternatively, you can just connect the towers together through some
sort of arbitrary feed system (or you can carefully cut a "phasing line"
-- you have the same probability of success with either method) and have
lots of fun seeing in which directions it seems to work well and which
it doesn't.

Roy Lewallen, W7EL

Denny wrote:
Short answer, no...
Long answer, yes...

And I cannot do a long answer justice here on a forum such as this...
Perhaps W7EL or W2DU will jump in here and rescue me...
The major issue you face is that the towers are shunt loaded which
creates phase differences between the two right from the git-go, even
when both are resonated... The fact that the feed points of the two
towers are initially out of phase needs to be tuned out in setting up
the 90 degree total phase difference...

Certainly it can be done... You will need to measure the input
impedence and reactance for each tower as built...It will take a
pick-up coil on each tower fed to an oscilloscope so that you can see
the phase difference as you adjust the phasing network / phasing lines
to reach the desired 90 degrees phase lag on the leading element...
Read W7EL's contribution to the ARRL Antenna Handbook on the subject of
properly phasing lines / antennas... This will give you enough
information to decide if you want to proceed...

I long ago decided life is too short for designing all driven arrays
when I can build, install, and tune, parasitic arrays in less time than
it takes me to work the equations for designing the needed phasing
networks for a driven array...

denny / k8do

Roy Lewallen wrote:
It's easy to see who's read Chapter 8 of the ARRL Antenna Book and who
hasn't! Denny has the right idea.

Thanks K8DO and W7EL you fellows have answered my questions and made me
realize that the one word that I was missing in all of this was
"current". Strange how one word can turn on the light bulb. I need to
get an updated Antenna Book, my old dog eared one is vintage 1965. Also
EZNEC wouldn't hurt either. I'll try the demo first even though it means
having to use Windows (I'm a Linux user). Thanks again.

John / K1BXI

John Phillips wrote:

Thanks K8DO and W7EL you fellows have answered my questions and made me
realize that the one word that I was missing in all of this was
"current". Strange how one word can turn on the light bulb. I need to
get an updated Antenna Book, my old dog eared one is vintage 1965. Also
EZNEC wouldn't hurt either. I'll try the demo first even though it means
having to use Windows (I'm a Linux user). Thanks again.

John / K1BXI


Hint hint Roy. There are a lot of us out here that use only, or almost
only, Linux.

That being said, is anyone running EZNEC under WINE?

tom
K0TAR

Tom Ring wrote:

Hint hint Roy. There are a lot of us out here that use only, or almost
only, Linux.

The "lot" comprises about 5% of the total market at the outside. Are you
willing to pay 20 times as much for EZNEC as Windows users?

That being said, is anyone running EZNEC under WINE?

At last report, EZNEC won't run under Wine. Wine malfunctions a couple
of places when attempting to run EZNEC, although I think I could
probably work around them. (Of course, there's always the danger that an
update or upgrade would break the program again, since there's no way I
know of to find out which Windows functions Wine emulates correctly and
which it doesn't.) I won't, however, make any attempt to work around the
Wine problems until Wine is able to open the manual, which it is wasn't
able to do at the last report I got. The manual was created with
RoboHelp, a popular help authoring tool, and there isn't any way for me
to work around Wine's inability to read it. If and when anyone reports
that Wine has advanced to where it's able to open the manual (EZW4.hlp),
I'll look again at the possibility of finding workarounds to Wine's
other problems with EZNEC.

EZNEC works fine under at least one Mac emulator, SoftWindows.

Roy Lewallen, W7EL

Roy Lewallen wrote:

Tom Ring wrote:


Hint hint Roy. There are a lot of us out here that use only, or
almost only, Linux.


The "lot" comprises about 5% of the total market at the outside. Are you
willing to pay 20 times as much for EZNEC as Windows users?


I would gladly pay double without a blink, and I doubt that it would be
that much work, in the long run, to make a Linux version. Your SW and
your call obviously, but you are making a very wrong assumption that
porting a version that runs under a different OS takes nearly the same
development effort.

I would gladly assist in making it work. I have no idea what language
it is written in, but as long as it is not in something MS specific it
shouldn't be that hard to port.

tom
K0TAR

Tom Ring wrote:

I would gladly pay double without a blink, and I doubt that it would be
that much work, in the long run, to make a Linux version. Your SW and
your call obviously, but you are making a very wrong assumption that
porting a version that runs under a different OS takes nearly the same
development effort.

I would gladly assist in making it work. I have no idea what language
it is written in, but as long as it is not in something MS specific it
shouldn't be that hard to port.

*Sigh*. I get this a lot.

The main program, 70,000 lines of code at last count, is in Visual Basic
6 and incorporates many direct calls to the Windows API for speed and
increased functionality. The calculating engines (a few tens of
thousands of lines of code) and some main program routines are in
Fortran, and make use of commercial math libraries for fast calculation
of some complex functions. The Fortran routines also make a limited
number of Windows API calls.

The port of a functioning EZNEC program from DOS to Windows, back when
EZNEC was somewhat smaller, took me about two years of full time work.
After some short experiments with VB.NET, it looks like a port to that
(Windows) language probably would take something like six months, plus
an unknown amount of time to find and solve the huge number of subtle
bugs caused by the port. But not only would the user not gain anything,
there would actually be a negative impact, so I don't plan on doing it.
Converting to a C Windows program would probably be a one or two year
project. That might make it easier, although by no means simple, to port
to Linux, but would be of no benefit to Windows users so the Linux
market would have to pay for the effort. Sorry, you'd need to pay a lot
more than twice the current price. (I happily run my EZNEC business for
a fraction of what I can make doing consulting, but I don't work for
nothing. Contrary to what seems like a common perception, I'm not
retired but earn my living from EZNEC and consulting.)

I encourage anyone who thinks it's a simple matter to develop a Linux
program of the level of EZNEC to have at it. It's an untapped market.

Roy Lewallen, W7EL

Roy Lewallen wrote:

I encourage anyone who thinks it's a simple matter to develop a Linux
program of the level of EZNEC to have at it. It's an untapped market.

And it points out that when people look into buying a computer or
operating system, they should pick what tools (software) they want to
run, and build their system around that. Most people buy a computer or
install an OS, then want vendors to write for that.

I'm coming in a little late on this discussion, has EZNEC been tried on
the Intel based Mac's running windoze?

- 73 de Mike KB3EIA -

Roy Lewallen wrote:


I encourage anyone who thinks it's a simple matter to develop a Linux
program of the level of EZNEC to have at it. It's an untapped market.

Roy Lewallen, W7EL

Sorry, I didn't know it was in VB. I can understand how that makes it
nearly impossible as I have worked where we had to do what you did going
from DOS basic to Windows VB. I was hoping it was in something like C.

I know what it's like to have an outsider ask you to port something
that's large and then be surprised when told how long it would take.
Ericsson was a bit miffed at me when told how long to port my US
(Honeywell) version of the MD110 PBX database regenerator to an
international version, and mine was all text based C.

Thanks for the response Roy.

tom
K0TAR

I'd like to add a question.

Why, instead of trying to get the Windows program developers to spend
countless hours developing programs for the minuscule Linux market,
don't the Linux users spend a little time getting Wine to work properly?
If it seems to simple to port programs to Linux, why is it so hard to
get open-source Wine to work?

Roy Lewallen, W7EL

Roy Lewallen wrote:
I'd like to add a question.

Why, instead of trying to get the Windows program developers to spend
countless hours developing programs for the minuscule Linux market,
don't the Linux users spend a little time getting Wine to work properly?
If it seems to simple to port programs to Linux, why is it so hard to
get open-source Wine to work?


I have a computer with Linux installed. Perhaps I is a dummy, but even
just installing programs, or searching for drivers is a nuisance. I'm
always told how such and such flavor of Linux doesn't have that problem,
but I'm on flavor number three, and still waiting for I don't have
enough experience in it to make a firm judgement, but I think we are
supposed to be happy if the operating system and hardware just works,
let alone the software.

Awaiting my one-way trip to Linux hell for what I just wrote....

- 73 de Mike KB3EIA -