Antennaware
[Top] [All Lists]

[Antennaware] FW: Fwd: Modelling yagi split DE

To: <antennaware@contesting.com>
Subject: [Antennaware] FW: Fwd: Modelling yagi split DE
From: "Matt" <maflukey@gmail.com>
Date: Wed, 9 Jul 2014 19:29:58 -0500
List-post: <antennaware@contesting.com">mailto:antennaware@contesting.com>
Hi Charlie,

Just wanted to throw in a little more info that might be of benefit...

The real life feed point actually starts where the wires first split off of
the core inside the balun - one can observe this in measuring the
performance of a balun from where the load side connection is made - as soon
as the test points are moved outward from the core, the reactance begins to
show up in the measurements.  So for practical purposes, modeling the DE as
a single, center fed element under NEC 4 produces reasonable results.  In
reality, the model should be able to get you close to the right length and
trim it off in the field from there...

To reinforce the point that Guy brought up, I have read that NEC 4 does not
seem to handle abrupt changes in geometry (such as aggressive tapering
and/or abrupt changes in direction) within finely segmented areas very well.
I have found this to be true in my own experience.  You might want to revert
back to NEC 2 for these cases which seems to produce more realistic results,
albeit with the limitations of that engine.

Hope this is of some value to you.

Matt
KM5VI


-----Original Message-----
From: Antennaware [mailto:antennaware-bounces@contesting.com] On Behalf Of
Charlie Ocker via Antennaware
Sent: Wednesday, July 09, 2014 5:59 PM
To: k2av.guy@gmail.com; AntennaWare
Subject: Re: [Antennaware] Fwd: Modelling yagi split DE

Hi Guy -

Thanks for the thoughtful response.  What I was trying to do is model the
effect of the actual split DE and it being fed by #12 wire balun leads.
Maybe this is overkill.  It does make sense that the NEC engine might have a
problem with the abrupt taper difference.

I'll try your suggestions regarding wire segment length.  Right now, I am
using the EZNEC automatic "conservative" wire segmentation feature.

Thanks again for the reply - really appreciate having this reflector as a
technical resource.  There is no one in my immediate ham radio circle of
friends who dabble in antenna design and modelling.  And, I am a self
admitted hack, having had some success with it.  But, I do find it
fascinating!

Vy 73,
Charlie  N9CO

On 7/9/2014 3:17 PM, Guy Olinger wrote:
> Hi Charlie,
>
> You are modeling in an area of segment size where the segment center
> (node) space can affect the results.
>
> Reduce the segment size in the model to the region of six, five or 
> four inches, and apply that to the entire antenna. Start with segment 
> counts for wires which give the region of four inchs and only lengthen 
> if the segment count is too high for your program version. This should 
> be done in YO as well, though it uses a different mechanism for 
> establishing what amounts to segment size.
>
> On 160m I use fine grain one foot segments until the design is set. 
> For passing along the design to others, I reduce the number of 
> segments until the results start to change, and then back off a bit to 
> get the fewest segments that **still get the same results as the 1 
> foot segments**. While I am using EZNEC Pro which supports gobs of 
> segments, even the early EZNEC will support much finer segments than you
are using.
>
> On your second method, what was the rationale for dropping from inch 
> diameter tubing to number 12? That what actually happens?
>
> There is a modeling gotcha advisory to not place a source in a segment 
> adjacent to a junction of more than two wires or adjacent to a wire 
> with a widely divergent diameter, or widely divergent segment length. 
> While this does not effect all models, it clearly poxes enough to stay 
> away from it.
>
> Remember that models are creatures of algorithms and math. Most of 
> these strange issues have to do with the need to do many things with 
> the same math, just to have a program which is affordable to code. 
> There are just places where the math can't deal with an issue, without 
> the expense of writing exception code to handle it.
>
> 73, Guy K2AV
_______________________________________________
Antennaware mailing list
Antennaware@contesting.com
http://lists.contesting.com/mailman/listinfo/antennaware

_______________________________________________
Antennaware mailing list
Antennaware@contesting.com
http://lists.contesting.com/mailman/listinfo/antennaware

<Prev in Thread] Current Thread [Next in Thread>