High Frequency Irradiation Problem

Troy_S

Description: solving twisted cable irradiation at high frequency (50 Ghz) appears to require MTL since the calble is not shielded. However, MTL requires distance above GND to be Lambda/5. However, twisted cable radius is > Lambda/5 which means cable conflicts with GND. Appears to be impossible to solve. And MoM requires a shield to solve. How to solve twisted pair at 50 GHz?

Product/Topic Name : [Feko 2025]

Torben Voigt

Hi @Troy_S ,

I had the same problem at first, because the new mesh engine in Feko 2025 obviously needs some fine tuning. The curved wires are meshed with default settings with very short segments, which leads to an error (as soon as a segment is shorter than 5x the length of the segment). This can be avoided by using a local mesh size:

Best regards,
Torben

Torben Voigt

Hi @Troy_S ,

The only thing I could think of would be to model the twisted pair as wire Helix and then simulate it with MoM. If the cable path is simple, that wouldn't be a problem. I'll attach an example soon.

Best regads,
Torben

Torben Voigt

Here's the model:

This approach is obviosly not ideal, but without a groundplane within lambda/5 probably the only way.

test_irradiated_twisted_pair_50GHz.cfx

Hope this helps!

Best regards,
Torben

Troy_S

Torben, Thank you, this is very helpful and makes sense. I set the following variables:
twp_core_radius to .039" (20 awg wire)
twp_insul_thickness to .021" (thickness of insulation)
twp_radius to .060" (radius of the twisted pair)
However, I get "ERROR 116: The ratio of the segment radius to length is too large". radius/length = 3. It appears the helix wire spline is broken into short segments, which exceed the ratio.
How do I get around that error?
Again, thank you!

Torben Voigt

Hi @Troy_S ,

I had the same problem at first, because the new mesh engine in Feko 2025 obviously needs some fine tuning. The curved wires are meshed with default settings with very short segments, which leads to an error (as soon as a segment is shorter than 5x the length of the segment). This can be avoided by using a local mesh size:

Best regards,
Torben

Troy_S

Thank you very much! That solved the problem. The local mesh must be made small enough, but I can't tell what it depends on.

I tried making the wire radius smaller but it didn't affect the local mesh requirement.

I changed the twist angle/pitch… no difference.

If I made the overall length of the helix shorter, then the local mesh size can be greater… but if I make the length longer, the local mesh requirement doesn't change.

Do you have a formula for a rough mesh size limit when modeling helix (twisted pair wires)?

Torben Voigt

Hi @Troy_S,

Unfortunately, I can't give you a formula, as the new mesh engine is still a bit idiosyncratic at the moment. What I have done:

1. Model the helixes with parameters taken from your cable model (wire radius, pitch length, insulation thickness etc.)
2. Set the frequency to 50 GHz and realised that the mesh segments are quite small
3. Defined a local mesh length in the wires, increased the value until the mesh segments were "long enough" (> wire_radius/5).

In my case (Feko 2025.0) I had to set the value to 10 mm. However, this may depend on the Feko version, as the mesh engine is likely to be improved.

The solver throws warnings as soon as a mesh segment is shorter than wire_radius/5.

Best regards,
Torben

Troy_S

The model you sent does work, but it breaks easily when I change the wire length, radius, or pitch. Making the local wire mesh smaller doesn't always work.

Sometimes, even if I keep the wire length the same, but use a number rather than a variable to represent it, it will error "radius to length ratio". When I put back the variable it works.

It is very difficult to find a local wire mesh size that works. It seems the length, radius, pitch and possibly even a bug in the program are interacting in an unpredictable manner to often cause this error.

I will try version 2024 to see if it is better…

Torben Voigt

Hi @Troy_S

Yes, it's the new mesh engine. You could call this a bug. I am convinced that this will soon be fixed. The problem shouldn't actually occur in Feko 2024.

My suggestion for a workaround:

Best regards,
Torben

Troy_S

Thanks again for the response. I tried using the pitch length for the mesh size but still error.
I found that when local mesh size is too small, I get errors 115,117:
Segment 1 is too long (length/lambda= 4.99280E-01) 

WARNING   115: Coarse segmentation for wire segments 

     Segment 1 is too thick (radius/length= 3.30905E-01) 

WARNING   117: The ratio of the segment radius to length is too large 

And when local mesh is too large, I get error 114

Segment 1 is too long (length/lambda= 5.00028E-01) 

ERROR     114: Segmentation rules have been violated (wire segment is too long) 

There is no happy medium. Just 0.001" larger or smaller switches the error back and forth.
My model is attached. I'm using a relaxed pitch of .5 twists-per-in, 100" cable, 50 GHz, local mesh size of 0.118". Any smaller triggers the different error.

test_irradiated_TP_50GHz_rev4.cfx

Torben Voigt

Hi @Troy_S,

I'm afraid I was a little premature with my blame for the new Mesh Engine. I didn't realize that we are working at 50 GHz here, which means that the wavelength and therefore the required mesh size are correspondingly small.

freq: 50 GHz
lambda: 0.2361 inch
lambda/12: ~0.02 inch
lambda/8: ~0.03 inch

When not using any local mesh setting but just using "standard" mesh size (= lambda/12), the resulting average segment length is 0.0196768081225922 inch

-> mesh size is justified

When not using any local mesh setting but just using "coarse" mesh size (= lambda/8), the resulting average segment length is 0.0295066644553952 inch

-> mesh size is justified

In other words: We have a problem. For wires Feko uses the "Thin Wire Approximation" which is a quick way to compute currents along wires. It makes the assumption that the field is the same radially around the segments, which is true for very thin wires. However, as soon as a segment is thick (> 5* radius), Feko will issue a warning or an error.

With your desired wire radius of 0.039 inch, the minimum length of the segments would therefore be 5x0.039 inch = 0.195 inch = 0.83 lambda. Segments must not be significantly longer than lambda/8 for accurate calculation of the currents, and here we have the dilemma.

Even if one would agree to measure the segments with lambda/5, the ratio radius/length is still too large and the solver will stop.

You could deactivate mesh checking and thus force the solver, but it is difficult to say whether the results are accurate:

Idea: You could simulate a comparative model where you simulate the cable with actual thickness. To do this, you could create two discs at the end of the helixes and then run them along the helixes using Path Sweep:

I reduced the length of the cable to 10 inch, but you may expect high memory and runtime for this model. If the results match with the wire approach (with deactivated mesh checking) you're ready to go.

Example model is attached. Please keep me updated.

Best regards,

test.cfx

Torben

Troy_S

Torben, Thank you very much for the explanation! So, accuracy requirements dictate the wire segment must be both:
shorter than lambda/8 and longer than radius*5

If I represent my .039" radius in terms of lambda (lambda/25), this requirement impossibility becomes clear:
shorter than lambda/8 and longer than lambda/5 ← impossible

I can re-write lambda/8 and radius*5 requirements as: lambda > radius*40

written in terms of frequency: radius*freq < Co/40

so if radius is .039, freq < 7.6 GHz
of if freq is 50GHz, radius < .006"

Thank you for the way to disable this requirement.
Thank you for suggestion using discs to compare the resultant error if I turn off the mesh checker.
I suppose I can also check the resultant error by comparing with a cable harness with MTL solver. It seems the MTL solver doesn't have this segment length requirement, but it does have a height above the ground plane requirement (h < lambda/5) which, of course, I also exceed.