Jump to content

Torben Voigt

Members
  • Content Count

    90
  • Joined

  • Last visited

  • Days Won

    2

Torben Voigt last won the day on February 16

Torben Voigt had the most liked content!

About Torben Voigt

  • Rank
    Advanced User

Profile Information

  • Country
    Germany
  • Are you University user?
    No

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Hi @Marcus Chang, For the corner reflector you're using PO, but with PO no multi-reflections between PO faces are taken into account. A corner reflector is THE classical example where PO is not feasible. Furthermore, the asymptotic methods (PO, LE-PO, RL-GO and UTD) are only feasible if the model is electrically very large, e.g. 20 lambda, bigger is better, but the corner reflector is only around 4 lambda. You should definitele use MoM / MLFMM here. Same goes for the sphere, which is only 3 lambda in radius. When calculating the scattered field of the reflector and the sphere correctly (MoM), the received power of the reflector is around 10 times higher than that of the sphere.
  2. Hi @Marcus Chang, If you get identical far field results for both, then I assume you have in addition "Calculate only the scattered part of the field" activated: This will in this model of course give the same results, as the sphere is the only scattering object. So, in both cases you will get the scattered field from the sphere surface.
  3. Hi @Marcus Chang, Unfortunately I'm not sure about the Matlab code. Maybe someone else (@mel, @JIF) could have a look? You can get the far field pattern of the reflected field of sphere by doing this: This will then only use the contribution of the surface currents of the sphere.
  4. Hi @Marcus Chang, Let check what you did: In horn_X band_190309.cfx you calculate and save the near field and the far field of the horn antenna. In FF source_PEC sphere_sphere surface NF source_190312.cfx you replace the horn by the near field data from 1. and to illuminate a PEC sphere. Here's mistake #1: The orientation of the near field is wrong (the horn is looking downwards): This would be correct: Mistake #2: The near field data is placed at z=0, while in model 1. it is placed at z=0.2138m. Around the PEC sphere you request a new near field to capture the radiated field from that sphere. Here's the mistake #3: The near field request has the same radius as the sphere, so the near field point are calculated exactly on the PEC surface. For acurate near field results a field point should not be closer than 1.5 x the edge length of the surface mesh. In temp_190313.cfx you compare the received power of an RX near field antenna and an RX far field antenna. The results are different because of mistake #2 and also because of warning WARNING 39270: A receiving antenna described by a far field pattern is positioned too close to a scatterer, far field condition not met. It says that that a source (the field of the PEC sphere) is too close to the RX far field receiving antenna. In general for far field sources (or receiving antennas) a far-field radius should be considered. I also decreased the increment beween the near field points of model 1. to ensure accuracy. The final results agree quite well: Note, with larger distance between source and RX antenna (or plane wave instead of the near field of the PEC sphere) the difference would be around 0.2 dB, because of omitting Warning 39270. The three new model files are attached: NF_vs_FF_RX_antenna.zip
  5. Torben Voigt

    Element Gain Pattern

    Hi @Bidisha Barman, Maybe you can make use of the "Scope" in the far field request. There you can select which faces/wires are taken into account for the far-field calculation. You could for example select only those faces from the one element you're interested in.
  6. Hi @Marcus Chang, I would need the *.cfx files to investigate.
  7. Hi @Marcus Chang, In the model where the near field is requested, the Start and End values of U are defined from positive to negative: Therefore when trying to use as near field source, you should rotate the workplane of the source (or of the field data) so that the orientation agrees with the original model.
  8. Torben Voigt

    design of meander line antenna for the frequency of 2.5Ghz

    Hi @elaiyabharathi, The basics of Feko are easy to learn by having a look at the GettingStarted.pdf and the ExampleGuide.pdf (...\Altair\2018\help\feko\pdf). But of course feel free to attach a descrption of the geometry here and I will be happy to assist.
  9. Torben Voigt

    Halfwave Balun

    Hi @FEKOFan, Connecting MTL cables with MoM pots is unfortunately not supported. MTL cables interact with the surrounding only via radiation/irradiation. What may be possible is to cumpute s11 of the dipole, save as touchstone file and include this in your CableHarness. Question: Why do you want to model the Balun? Applying a voltage source directly to your antenna would basically represent an ideal Balun. Just saw that you wrote the goal in the original post: If you want to simulate the effect of the actual cable as radiating object, you would have to actually model the feeding cable and Balun cable. This would of course be quite an effort. I will have to discuss with a colleague if there is a better way to do this.
  10. Hi @FieldForcer, Mesh IDs are only present in POSTFEKO. They are shown if you press Ctrl+Shift ('snapping keys') and move the mouse over a triangle in a 3D view. The geometry is not present in POSTFEKO. In CADFEKO there is no connection between mesh and mesh IDs (these are created during solving). Solve your Skull model and look at the surface currents in POSTFEKO Save the model under different name in CADFEKO Delete / Exclude those areas of the geometry where the surface currents are lower than your desired threshold (compare with POSTFEKO). (you can e.g. add cuboids and then subtract them from the skull, use 'Split', etc.) Solve the new model and read the total surface in the out file.
  11. Hi @FieldForcer, I don't think there is a direct solution for this in either CADFEKO and POSTFEKO. FEKO does compute the total surface of all mesh elements and reports in the out file. But users can't select certain triangles and calculate that surface only. One possible (and probably elaborate) workaround could be to create a second model where you exclude all faces where the currents are below a certain threshold. When simulation this reduced model, the total surface will be written to the out file.
  12. Torben Voigt

    Halfwave Balun

    Hi @FEKOFan, You have to set the CableHarness to "Radiating" or "Radiating (taking irradiation into account)": If a source is applied to a cable, it must not be considered purely irradiating, that's why the error occurs.
  13. Hi @FieldForcer, You're right, sorry. Seems I confused things. In the *.os file the center of the mesh triangles is written. The ID of each triangle can be found in POSTFEKO by using "Find elements". The only way to find out the positions of the vertices of each triangle would be looking up in POSTFEKO. By using "Ctrl+Shift" you can snap the cursor to vertices and read the coordinates in the bottom line. Could you describe why exactly you want to know the vertices? Maybe there is a different way to achieve your goal.
  14. Hi @FieldForcer, The location of the three vertices is given in the *.os file: 1st column: mesh triangle ID 2nd column: vertice x coordinate 3rd column: vertice y coordinate 4th column: vertice z coordinate In POSTFEKO you can find a triangle by its ID:
  15. Torben Voigt

    Simple Microstrip with MoM

    Hi @BrianFEKO, Any kind of port calibration would have to be done manually, e.g. with the help of lua scripting in POSTFEKO (e.g. adjusting S11 with some calibration model). Unfortunately I'm not an expert on this.
×